Міністерство освіти і науки України НУ »Львівська політехніка» Звіт З дисципліни: Основи командної розробки Розробив: Група ПІм-41з Перевірив: Климаш Т.С. м. Хмельницький 2012 Тема: Архітектура проекту у Visual Studio. Мета: розробити архітектуру проекту у Visual Studio. Коли проектується архітектура додатка, все красиво, логічно і відповідає кращим світовим практикам. Але в процесі роботи, стикаючись з обмеженнями пропонованими архітектурою, ми часто думаємо: «Ось тут трошки порушу, адже це заощадить мені годину часу розробки. Ну а потім, як буде час, поправлю ». Але, чомусь, цей час так ніколи і не настає. На мій погляд, єдиним способом змусити себе, як програміста, слідувати розробленій архітектурі, це навчити середовище розробки всі відхилення і милиці показувати як помилки компіляції. У цьому випадку, якщо код поганий, він відразу буде виправлений, ну а якщо архітектура застаріла, то буде виправлена ​​вона. Тобто в сховище коду завжди буде код відповідної запланованої архітектурі.  Пара слів, про те, що буде підкатом: Невелика преамбула. Відновлення архітектури за наявним проектом. Налаштування Visual Studio і TFS для автоматичного контролю архітектури. Підготовка демонстраційного проекту Для демонстрації роботи з Layer Diagram, візьмемо проект, трохи ближчий до реальності. Нехай буде шар доступу до даних (Entity Framework) і, власне, шар клієнтських додатків в якому також буде шарувата структура (MVVM). У клієнтському рівні модель буде братися з першого шару, а от шари View і ViewModel будуть розмазані по декільком зборках. Ось так, ці чотири проекти виглядають після створення: / Рис.1 Можна змінити Namespace за замовчуванням для створюваних зборок. У цьому прикладі, для 3-х клієнтських зборок заменяєм Default Namespace: / Рис.2 Додаємо в проект DAL базу даних і Entity Model. У клієнтських проектах створюємо папки View і ViewModel. Додаємо в них тестові компоненти й класи: Рис.3 Додавши посилання між проектами, звернення між створеними компонентами і класами, можна отримати граф залежностей приблизно такого вигляду: / Рис.4 Якщо розбиття на шари, йде на рівні зборок, то у зв'язку із забороною на циклічні посилання між збірками (інакше не можна визначити порядок побудови), можлива тільки проблема «звернення через шар». Якщо ж у проекті, як в даному випадку, шари розмазані по декільком зборках, причому в рамках однієї збірки є представники різних верств, перетягування проектів / файлів з ​​Solution Explorer-а в Layer Diagram виявляється не ефективним. І тут на допомогу приходить Architecture Explorer, який викликається з головного меню: Architecture -> Windows -> Architecture Explorer. Відразу після відкриття він матиме вигляд: / Рис.5 Відновлення діаграми шарів з артефактів рішення  Додаємо в рішення модельний проект, вже в нього додаємо Layer Diagram: / Рис.6 Тут ми можемо перетяуть з Toolbox-а шари, намалювати залежності, потім довго і наполегливо в ці шари переносити класи з клієнтських проектів. І все це тільки для того, щоб вже на наступний день, коли розробник додасть новий клас, про який ми не знаємо, і до шарів він не прив'язаний, а отже перевірка перестане працювати. Щоб цього уникнути, нам і придасться Architecture Explorer. / Рис.7 Зверніть увагу, що всі класи ViewModel опинилися в одному просторі імен (ну нехай в реальному проекті вони будуть в 3-5), і нам тепер можна в діаграму шарів додавати не класи, а цілком простору імен. Виділяємо їх і, не створюючи ніяких шарів, перетягуємо на нашу Layer Diagram:/ Рис.8 До речі, можемо скористатися і функціоналом перетягування проектів з Solution Explorer-а. З Shift-ом виділяємо в ньому ClientApp1, ClientApp2 і Base.Library, хапаємо лівою кнопкою миші і перетягуємо на вільне місце в Layer Diagram: / Рис.9 Перейменовуємо новий шар в Presentation, виділяємо два шари (View і View Model) і перетягуємо їх в шар Presentation: / Рис.10 Практично все готово, бракує тільки зв'язків. Для того, щоб їх згенерувати, досить викликати контекстне меню на Layer Diagram-е і ви...